-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decouple the Clipboard API from fyne.Window #5121
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. I changed the base branch to develop and that made the changes look a lot more sensible. Just added a small comment about that we perhaps should consider changing a function signature (if you agree with me there) :)
@pierrec Please don't force push your changes very time. Descriptive commits with are lot better as we more easily can see what has changed and GitHub also has a tendency to sometimes lose track of old review comments. We'll squash on merge if needed. |
OK, so sorry, will just push next time. |
Question while working through the CI failures (a lot of them due to my lack of knowledge of the Fyne codebase and all the build flags!): |
I think there may have been a confusion about word usage here - so I want to ensure we are on the same page.
I think that @dweymouth was suggesting that the clipboard exist inside the app instance instead of inside the window where it was before. That is neither a true singleton, but exists only once per application. It will be much more efficient than the current implementation which seems to allocate a new clipboard for every situation where it may be used. |
I'm really not sure that it is a correct assumption. All of our clipboard structs are zero size as I can remember and don't actually contain any information so allocating extra size for the interface is unnecessary? We can probably just avoid returning a pointer to the struct and help it not allocate that way. I don't think it is worth making the app struct larger just for an arbitrary optimisation that we don't if it is worth it or not. Getting the clipboard is likely not a hot path in any application and if anyone cares, they can just save it to a variable themselves and be happy there. |
Sorry for the long turnaround time for me reviewing this. I've had quite a busy first weeks with the first weeks of my masters program. I'll try to have a look one of the coming days. |
Thank you for the update, there is no rush :). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the very long wait. Just one minor change needed and we're golden :)
internal/driver/mobile/driver.go
Outdated
@@ -100,6 +100,10 @@ func (d *driver) currentWindow() *window { | |||
return last | |||
} | |||
|
|||
func (d *driver) Clipboard() fyne.Clipboard { | |||
return &mobileClipboard{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should return a value and not a pointer for consistency? Maybe even use the NewClipboard()
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one slipped through. Will do.
The static analysis test failure seemed a bit strange. Kicked it to see if it is temporary. |
I had a look but I dont even have that statement on line 406 of the file; grepping doesnt return any instance of it either. Ad running it locally returns errors but not that one:
|
Add NewSelectWithData function. Add Select.Bind and Select.Unbind methods to bind a string to Select.Selected.
Test that binding actually occurred.
Currently translated at 100.0% (39 of 39 strings) Translation: Fyne/Fyne Translate-URL: https://hosted.weblate.org/projects/fyne/fyne/sv/
This mainly does two things: - Uses Go 1.22 instead of 1.21 as the highest version (I don't have 1.23 on Fedora 40 yet so did not want to bump to latest just yet). - We now always pull the latest setup-go-faster action in v1 without having to manually change version.
This fixes a few code errors that slipped through review (thankfully now handled by Staticcheck for us) and makes sure we are using the latest version.
Haven't quite gotten used to Nvim yet ;)
This should be safer than ever given that some new features are dependent on the version in go.mod.
Still erroring out. At this point I might close this PR and make another one. |
Let me just check out your branch locally to see if there is anything strange going on there before you do anything :) |
It does indeed still error out but the line it points to happens to be a perfect valid error that easily can be fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this. I'm really sorry for the long turnaround time and all the problems that popped up. Hopefully it will be smooth sailing for any future contributions :)
Thanks for the review! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Questioning some removed code.
The test failure looks like a reduction in code coverage - It isn't an obvious lack in this PR but I wonder if somehow it has redirected code to be less well tested. The Coveralls report should lend a hint.
func shortcutFocused(s fyne.Shortcut, w fyne.Window) { | ||
switch sh := s.(type) { | ||
case *fyne.ShortcutCopy: | ||
sh.Clipboard = w.Clipboard() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing this code looks like it is possible that the shortcut for copy.paste etc could some times be missing the clipboard info which as previously there..?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I can tell from the code, it was always setting the clipboard twice. First when creating the struct and then this function made a type switch and set it again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andydotxyz the shortcut is already setup with the clipboard at instanciation. No need to do it a second time right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the shortcut is already setup with the clipboard at instanciation.
In the instantiation you make, yes - but check other usages too - like in Entry...
e.shortcut.AddShortcut(&fyne.ShortcutCopy{}, ...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. It may be better to get ShortcutCopy/Cut/Paste from the App though instead of relying on the user to properly instantiate it. In the meantime, I will restore the check in the fyne_demo app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be better to get ShortcutCopy/Cut/Paste from the App though instead of relying on the user to properly instantiate it
I agree with this statement, however having the fields be nil
would be a breaking change, so thanks for re-instating it.
Excellent thanks so much, I think we just need the approval of changes from @dweymouth now too. The coverage issue persists but without it going to coveralls I cannot see what the issue is. I'm happy that you have added tests so I can merge this after changes are approved and we can continue to investigate the 63% coverage failure. |
Description:
This PR implements the changes for #4418 by:
Fixes #4418
Checklist:
I dont see any automated tests for this but maybe I missed them. I did test manually and ctrl-c, ctrl-v and ctrl-x work as expected on the desktop.
I get quite a few errors on my system, some related to the locale (labels are emitted in French while tests expect English), others to something else which I dont know about.
They all seem unrelated to this change though.
Where applicable:
(no new module imported)